Software  Engineering  Institute 


Introduction  to  the  Architecture  of  the 
CMMI®  Framework 


CMMI  Architecture  Team 

July  2007 


TECHNICAL  NOTE 

CMU/SEI-2007-TN-009 


CMMI  Initiative 

Unlimited  distribution  subject  to  the  copyright. 


Carnegie  Mellon 


This  report  was  prepared  for  the 


SEI  Administrative  Agent 
ESC/XPK 
5  Eglin  Street 

Hanscom  AFB,  MA  01731-2100 

The  ideas  and  findings  in  this  report  should  not  be  construed  as  an  official  DoD  position.  It  is  published  in  the  in¬ 
terest  of  scientific  and  technical  information  exchange. 

This  work  is  sponsored  by  the  U.S.  Department  of  Defense.  The  Software  Engineering  Institute  is  a  federally 
funded  research  and  development  center  sponsored  by  the  U.S.  Department  of  Defense. 

Copyright  2007  Carnegie  Mellon  University. 

NO  WARRANTY 

THIS  CARNEGIE  MELLON  UNIVERSITY  AND  SOFTWARE  ENGINEERING  INSTITUTE  MATERIAL  IS 
FURNISHED  ON  AN  "AS-IS"  BASIS.  CARNEGIE  MELLON  UNIVERSITY  MAKES  NO  WARRANTIES  OF 
ANY  KIND,  EITHER  EXPRESSED  OR  IMPLIED,  AS  TO  ANY  MATTER  INCLUDING,  BUT  NOT  LIMITED 
TO,  WARRANTY  OF  FITNESS  FOR  PURPOSE  OR  MERCHANTABILITY,  EXCLUSIVITY,  OR  RESULTS 
OBTAINED  FROM  USE  OF  THE  MATERIAL.  CARNEGIE  MELLON  UNIVERSITY  DOES  NOT  MAKE 
ANY  WARRANTY  OF  ANY  KIND  WITH  RESPECT  TO  FREEDOM  FROM  PATENT,  TRADEMARK,  OR 
COPYRIGHT  INFRINGEMENT. 

Use  of  any  trademarks  in  this  report  is  not  intended  in  any  way  to  infringe  on  the  rights  of  the  trademark  holder. 

Internal  use.  Permission  to  reproduce  this  document  and  to  prepare  derivative  works  from  this  document  for  inter¬ 
nal  use  is  granted,  provided  the  copyright  and  "No  Warranty"  statements  are  included  with  all  reproductions  and 
derivative  works. 

External  use.  Requests  for  permission  to  reproduce  this  document  or  prepare  derivative  works  of  this  document  for 
external  and  commercial  use  should  be  addressed  to  the  SEI  Licensing  Agent. 

This  work  was  created  in  the  performance  of  Federal  Government  Contract  Number  FA8721-05-C-0003  with  Car¬ 
negie  Mellon  University  for  the  operation  of  the  Software  Engineering  Institute,  a  federally  funded  research  and 
development  center.  The  Government  of  the  United  States  has  a  royalty-free  government-purpose  license  to  use, 
duplicate,  or  disclose  the  work,  in  whole  or  in  part  and  in  any  manner,  and  to  have  or  permit  others  to  do  so,  for 
government  purposes  pursuant  to  the  copyright  license  under  the  clause  at  252.227-7013. 

For  information  about  purchasing  paper  copies  of  SEI  reports,  please  visit  the  publications  portion  of  our  Web  site 
(http://www.sei.cmu.edu/publications/pubweb.html). 


Table  of  Contents 


Abstract  iii 

1  The  CMMI  Framework  1 

2  The  CMMI  Model  Foundation  3 

3  The  Structure  of  CMMI  Models  7 


SOFTWARE  ENGINEERING  INSTITUTE  |  i 


List  of  Tables 


Table  1:  Model  Structure 


7 


ii  |  CMU/SEI-2007-TN-009 


Abstract 


This  document  is  an  introduction  to  the  CMMI®  (Capability  Maturity  Model  "  Integration)  Frame¬ 
work  architecture,  which  guides  how  CMMI  products  are  developed  and  integrated.  The  architec¬ 
ture  describes  the  structure,  terminology,  and  required  content  of  every  CMMI  model. 
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1  The  CMMI  Framework 


Identification 

This  document  introduces  the  architecture  of  the  CMMI  Framework,  which  is  used  to  create  CMMI 
models  and  their  associated  training  and  appraisal  materials  for  CMMI  version  1 .2  and  beyond. 

Framework  Overview 

The  CMMI  Framework  is  a  collection  of  components  used  to  construct  CMMI  models,  CMMI  training 
materials,  and  CMMI  appraisal  materials: 

•  The  model  components  include  process  areas,  goals,  practices,  and  informative  material  about  the 
use  of  the  model  and  its  components. 

•  The  training  components  include  guidebooks  on  implementing  the  model  and  audio-visuals  to  sup¬ 
port  teaching  how  to  use  the  model. 

•  The  appraisal  components  describe  the  process  of  appraising  the  organization’s  processes  against 
the  goals  and  practices  described  in  the  model.  They  also  include  training  for  performing  the  ap¬ 
praisal  process. 

A  purpose  of  the  CMMI  Framework  Architecture  is  to  control  the  selection  and  use  of  model  compo¬ 
nents  to  construct  CMMI  models  for  various  areas  of  interest.  When  building  a  new  CMMI  model,  de¬ 
velopers  use  existing  well-proven  components  that  fit  the  needs  of  the  new  area  of  interest.  Using  these 
existing  components  reduces  the  amount  of  training  needed  and  the  adjustment  of  existing  processes 
required.  The  framework  also  enables  newly  developed  models  to  retain  the  common  terminology  and 
structure  of  other  CMMI  models  in  the  framework  so  that  learning  the  new  model  will  be  based  on  fa¬ 
miliar  model  concepts. 

The  CMMI  Framework  is  a  collection  of  all  model  components,  training  material  components,  and  ap¬ 
praisal  components.  These  components  are  organized  into  groups  called  constellations,  which  facilitate 
construction  of  approved  models  and  preserve  the  legacy  of  existing  CMM  and  CMMI  models. 

In  the  framework,  there  are  constellations  of  components  that  are  used  to  construct  models,  training,  and 
appraisal  materials  in  an  area  of  interest  (e.g.,  acquisition,  development,  or  services): 

•  The  Acquisition  constellation  supports  an  organization  (or  project)  in  procuring  products  or  ser¬ 
vices  from  suppliers  outside  of  the  organization  (or  project). 

•  The  Development  constellation  supports  an  organization  (or  project)  that  develops  products  or  ser¬ 
vices. 

•  The  Sendees  constellation  supports  an  organization  (or  project)  that  delivers  services. 

Also  in  the  framework  is  a  CMMI  model  foundation  (CMF),  a  skeleton  model  that  contains  each  of  the 
components  that  must  be  included  in  every  CMMI  model.  A  CMMI  model  for  a  constellation  is  con¬ 
structed  by  inserting  additional  model  components  into  the  CMF. 
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A  constellation  may  share  some  components,  in  addition  to  the  CMF  components,  with  other  constella¬ 
tions.  It  also  may  have  some  unique  components  that  are  different  from  those  in  any  other  constellation. 
The  components  included  in  a  constellation  depend  on  the  purpose  of  the  constellation. 
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2  The  CMMI  Model  Foundation 


The  CMF  exists  within  the  CMMI  Framework.  The  CMF  contains  sections  for  each  of  the  following: 

•  front  matter 

•  generic  goals  and  generic  practices 

•  process  areas 

•  glossary. 

The  CMF  is  designed  to  provide  an  internally  consistent  set  of  components  that  must  be  included  in 
every  CMMI  model.  The  content  of  the  CMF  is  appropriate  to  the  areas  of  interest  addressed  by  all  con¬ 
stellations.  The  process  areas  in  the  CMF  have  no  additions,  no  generic  practice  elaborations,  and  no 
amplifications.  Certain  other  components  may  be  absent  because  they  are  not  appropriate  for  all  constel¬ 
lations.  To  achieve  maximum  reasonable  commonality,  the  CMF  process  areas  include  introductory 
notes  and  other  informative  material  that  appropriately  applies  to  all  constellations.  The  CMF  glossary 
includes  the  definitions  of  terms  used  in  the  CMF  components. 

In  other  words,  constellations  and  models  must  use  the  CMF  without  deleting  or  changing  any  of  its 
content.  Adding  process  areas,  specific  goals,  specific  practices,  specific  subpractices,  typical  work 
products,  generic  practice  elaborations,  glossary  entries,  and  front  matter  is  permitted. 

Suitable  additions  and  amplifications  may  already  exist  in  other  models  and  may  be  reused  in  the  mod¬ 
els  of  a  constellation  when  appropriate.  Preserving  commonality  by  reusing  existing  and  proven  model 
components  saves  time  and  reduces  confusion  when  training  people  on  new  material. 

To  make  changes  to  the  CMF,  change  requests  shall  be  submitted  to  the  CMMI  Architecture  team.  The 
CMMI  Architecture  team  will  invite  constellation  teams  to  participate  in  the  evaluation  of  change  re¬ 
quests  and  the  design  of  change  proposals  so  that  adverse  effects  on  the  constellations’  models  are 
minimized.  Once  changes  are  approved  by  the  CMMI  Architecture  team,  the  changes  are  subject  to  the 
configuration  control  processes  of  the  CMMI  Configuration  Control  Board  (CCB).  The  CCB  ensures 
that  the  implementation  of  the  change  proposals  is  consistent  with  the  CMMI  Framework  architecture. 

The  process  areas  in  the  CMF  are  as  follows: 

Causal  Analysis  and  Resolution  (CAR) 

Configuration  Management  (CM) 

Decision  Analysis  and  Resolution  (DAR) 

Integrated  Project  Management  (IPM) 

Measurement  and  Analysis  (MA) 

Organizational  Innovation  and  Deployment  (OID) 

Organizational  Process  Definition  (OPD) 

Organizational  Process  Focus  (OPF) 

Organizational  Process  Performance  (OPP) 
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Organizational  Training  (OT) 

Project  Monitoring  and  Control  (PMC) 

Project  Planning  (PP) 

Process  and  Product  Quality  Assurance  (PPQA) 

Quantitative  Project  Management  (QPM) 

Requirements  Management  (REQM) 

Risk  Management  (RSKM) 

Constellations 

Each  constellation  is  comprised  of  the  following  elements: 

.  the  CMF 

•  named  groups  of  additions  used  to  create  CMMI  models  within  that  constellation 

Two  examples  are  the  Engineering  group  of  additions  used  to  insert  the  Engineering  process  areas 
not  included  in  the  CMF  and  the  IPPD  group  of  additions  consisting  of  specific  goals  inserted  into 
IPM  and  OPF  to  create  the  CMMI-DEV  +IPPD  model. 

•  generic  practice  elaborations  for  the  process  areas  in  the  constellation  (optional) 

•  appropriate  training  and  appraisal  materials 

Change  requests  for  a  model  in  a  constellation  must  be  submitted  to  the  SEI  for  delivery  to  the  appro¬ 
priate  constellation  team.  The  constellation  team  evaluates  the  change  requests  and  designs  a  change 
proposal  so  that  none  of  the  constellations  and  their  models  are  adversely  affected.  If  the  change  pro¬ 
posal  will  change  the  CMF,  the  change  proposal  must  be  referred  to  the  CMMI  Architecture  Team. 
Once  changes  are  approved  by  the  constellation  teams  and  the  CMMI  Architecture  Team,  the  change 
proposal  is  subject  to  the  configuration  control  processes  of  the  CMMI  CCB,  which  ensures  that  the 
implementation  of  the  change  proposal  is  consistent  with  the  CMMI  Framework  architecture. 

CMMI  Models 

The  models  of  a  constellation  are  constructed  by  inserting  selected  groups  of  additions  and  selected 
groups  of  amplifications  into  the  CMF.  Generic  practice  elaborations  for  the  process  areas  can  also  be 
optionally  inserted  into  the  model. 

•  Each  addition  contains  a  reference,  glossary  entry,  note,  subpractice,  typical  work  product,  practice, 
goal,  or  process  area  that  is  inserted  into  the  CMF  to  extend  its  scope  or  emphasize  a  particular  as¬ 
pect  of  the  model’s  use.  The  addition  must  preserve  the  CMMI  model  structure.  For  example,  a 
practice  can  only  be  inserted  into  a  list  of  practices  within  a  goal. 

•  Each  generic  practice  elaboration  consists  of  informative  material  that  explains  how  the  generic 
practice  affects  a  particular  process  area  and  a  model  location  where  it  is  to  be  inserted.  The  elabo¬ 
rations  pertinent  to  a  process  area  are  placed  in  a  named  group. 

•  The  elaborations  and  additions  created  by  constellation  teams  are  subject  to  the  configuration  con¬ 
trol  processes  of  the  CMMI  CCB. 
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Naming  Rules  for  Selection  Within  a  Constellation 


The  name  of  each  produced  model  in  a  constellation  consists  of  the  letters  CMMI  followed  by  an  abbre¬ 
viation  of  the  constellation  name,  followed  by  the  names  of  the  addition  groups  included.  If  an  addition 
group  is  common  to  all  of  the  models  in  the  constellation,  its  name  is  not  included.  For  example,  a 
model  in  the  Development  constellation  would,  because  the  Engineering  process  area  addition  group  is 
common  to  all  of  the  models  of  the  constellation,  be  named  the  CMMI  for  Development  (CMMI-DEV) 
model.  After  the  IPPD  addition  group  is  inserted  into  the  model,  the  name  becomes  the  CMMI  for  De¬ 
velopment  plus  IPPD  (CMMI-DEV  +IPPD)  model. 

When  an  addition  not  common  to  all  of  the  models  of  the  constellation  is  inserted  into  a  component  of  a 
model,  the  components  that  enclose  the  addition  have  the  name  of  the  addition  group  in  their  names,  or 
a  different  style  of  marking  (e.g.,  grayed  in  a  box)  to  emphasize  that  the  component  was  altered.  The 
process  area  names  are  unique  within  a  constellation,  but  each  one  has  a  designator  for  the  constellation 
in  which  it  resides. 

For  example,  if  an  IPPD  addition  is  a  specific  practice,  either  the  specific  practice  title  must  include 
“+IPPD”  or  the  material  must  be  highlighted  and  labeled  clearly  as  an  “IPPD  Addition.”  If  the  naming 
option  is  used,  the  specific  goal  that  contains  the  added  specific  practice  must  also  have  “+IPPD”  in  its 
name.  Further,  the  process  area  that  contains  this  goal  must  have  “+IPPD”  in  its  name. 

Rules  for  Marking  Paragraphs  in  Models 

The  paragraphs  that  comprise  the  CMF  are  marked  at  the  end  of  the  each  paragraph  with  a  superscript 
of“  CMF.” 


The  paragraphs  that  comprise  the  additions  are  marked  at  the  end  of  each  paragraph  with  a  superscript 
of  its  acronym  (e.g.  “  DEV”).  If  these  paragraphs  are  shared  among  two  or  more  constellations,  both 
acronyms  are  listed  in  superscript  (e.g.  “  DEV  ACQ”).  These  markings  must  be  in  the  database  of  the 
CMMI  Framework;  they  may  or  may  not  be  in  a  printed  version  of  a  model. 

Complete  Insertion 

A  group  of  additions  is  completely  inserted  in  their  prescribed  locations  in  the  model  being  constructed. 
There  are  no  partial  insertions.  This  approach  ensures  that  every  model  is  the  same  every  time  it  is  gen¬ 
erated.  So,  CMMI-DEV+IPPD  is  the  same  every  time,  with  the  entire  IPPD  addition  group  inserted. 

Maturity  Level  Satisfaction 

For  each  releasable  model  that  is  constructed  using  the  CMMI  Framework,  each  process  area  is  as¬ 
signed  to  a  maturity  level  and  there  is  an  approved  target  staging  that  describes  the  process  areas  and 
capability  levels  that  are  necessary  for  each  of  the  maturity  levels.  The  process  areas  in  the  CMF  are 
permanently  assigned  to  maturity  levels  that  must  be  the  same  in  every  constellation. 

The  following  list  summarizes  the  rules  for  approved  target  staging: 

•  To  achieve  maturity  level  2,  all  process  areas  assigned  to  maturity  level  2  must  achieve  capability 
level  2  or  higher. 
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•  To  achieve  maturity  level  3,  all  process  areas  assigned  to  maturity  levels  2  and  3  must  achieve  ca¬ 
pability  level  3  or  higher. 

•  To  achieve  maturity  level  4,  all  process  areas  assigned  to  maturity  levels  2,  3,  and  4  must  achieve 
capability  level  3  or  higher. 

•  To  achieve  maturity  level  5,  all  process  areas  must  achieve  capability  level  3  or  higher. 

Shared  process  areas  are  staged  at  the  same  level  in  all  constellations.  If  a  shared  process  area  is  moved 
to  a  different  level,  its  name  will  be  different. 
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3  The  Structure  of  CMMI  Models 


CMMI  models  have  a  defined  structure.  This  structure  is  designed  to  provide  familiar  placement  of 
model  components  regardless  of  constellation  or  version. 

Model  Structure 

Table  1  illustrates  the  structure  of  all  CMMI  models.  If  a  component  name  in  the  Structure  of  the  Com¬ 
ponent  columns  of  the  table  is  singular,  then  there  is  only  one  component  of  that  name;  if  it  is  plural, 
then  the  number  of  components  of  that  name  is  unspecified.  If  a  component  name  has  quotes  around  it, 
it  appears  in  the  model  exactly  as  the  text  in  the  quotes.  The  components  that  contain  normative  items 

are  in  Bold  Font. 


Table  1:  Model  Structure 


Component 

Structure  of  the  Component 

CMMI  Model 

- 

Model  Name 

Front  Matter 

Generic  Goals 

and  Practices 

Section 

Process 

Area 

Sections 

Glossary 

Front  Matter 

= 

Preface 

Table  of 

contents 

Chapters 

Preface 

= 

“Preface” 

Notes 

Chapter 

= 

Chapter  Name 

Notes 

Generic  Goals  and 

Practices  Section 

“GENERIC 

GOALS  AND 

GENERIC 

PRACTICES” 

Notes 

Generic  Goals 

and  Practices  List 

“Applying 

Generic 

Practices” 

Notes 

Enabling 

Process 

Areas 

Enabling  Process 

Areas 

“Process  Areas 

that  Support 

Generic 

Practices” 

Notes 

Table  of  Generic 

Practice  and 

Process  Area 

Relationships 

Notes 
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Component 

Structure  of  the  Component 

Generic  Goals 

and  Practices 

List 

- 

“Generic  Goals 

and  Generic 

Practices” 

Notes 

Generic  Goals 

Generic  Goal 

- 

Generic  Goal 

Name 

Generic 

Goal 

Statement 

Generic 

Practices 

Generic 

Practice 

- 

Generic 

Practice  Name 

Generic 

Practice 

Statement 

Purpose 

Generic 

Subpractices 

Purpose 

= 

Purpose 

Statement 

Notes 

Generic 

Subpractice 

- 

Generic 

Subpractice 

Statement 

Notes 

Process  Area 

Section 

= 

Process  Area 

Heading 

Process 

Area  Body 

Process  Area 

Heading 

= 

Process  Area 

Name 

Associated 

Category 

Associated 

Maturity  Level 

Associated 

Constellation 

“Purpose” 

Purpose 

Process  Area 

Body 

“Introductory 

Notes” 

Notes 

References 

“Specific 

Practices  by 

Goal” 

Specific 

Goals 

Elaborations 

Specific  Goal 

- 

Specific  Goal 

Name 

Specific 

Goal 

Statement 

Notes 

Specific 

Practices 

Specific 

Practice 

- 

Specific 

Practice  Name 

Specific 

Practice 

Statement 

References 

Notes 

References 

Specific 

Practice  Body 

Specific  Practice 

Body 

- 

“Typical  Work 

Products” 

Typical 

Work 

Products 

“Subpractices” 

Subpractices 

Subpractice 

= 

Subpractice 

Statement 

Notes 

References 
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Component 

Structure  of  the  Component 

Note 

Text,  list, 

table, 

graph, 
diagram.  A 

note  is 

informative. 

Elaboration 

Generic 

Practice 

Name 

Generic 

Practice 

Stateme 

nt  (with 

Process 

Area 

Name 

inserted 

before 

“process'’ 

) 

“Elaboration” 

Notes 
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